Avoiding Knotty Structures in Design: Schematic Functional Programming

Designers in general have used diagrams and sketches to help in the process of creation. This is particularly so for system designers whose output is a set of programs. It would seem reasonable that the conversion of diagrams directly into a program would be desirable and yet the work of Green and Petre [12,13,14,19] and Citrin [8] has placed doubt on the viability of graphical programming notations. Some of this work is reviewed in this paper. The use of secondary notation and the matchmismatch hypothesis is reconsidered in the light of functional programming. It is proposed that much of the criticism of graphical notation is due to the imperative (or process orientated) nature of programming. Many of the limitations observed in using graphical notation are lifted when functional programming is used. Eight engineering dimensions and four engineering relationships (coherences) are proposed to describe programming environments (including notation). The key to the success of a functional language as a general representation as well as its coherence with a graphical notation comes from its unique extensibility. Support for these arguments is drawn from examples of a schematic programming language used for industrial scale projects. Nothing ever becomes real till it is experienced even a proverb is no proverb to you till your life has illustrated it. Keats, letter, 1819